I'd prefer if this caveat refered to the Reducer API from o1js in particular, and not to the general concept of actions and reducers.

At the protocol level, safe use of actions is very possible, if you implement a better reducer (the upcoming BatchReducer being an example).

Also, we should say why Reducer is not safe to use: Because the reduce() method breaks (completely) if more than a hard-coded number of actions are pending (default: 32).

I'd prefer if this caveat refered to the Reducer API from o1js in particular, and not to the general concept of actions and reducers.

Good idea. Do you think this location is still an appropriate place to add the caveat?

Also, we should say why Reducer is not safe to use: Because the reduce() method breaks (completely) if more than a hard-coded number of actions are pending (default: 32).

This was the plan. I was deciding if it made sense to either have a short description in this location with the caveat or to link to a longer description somewhere else, and where a long description would live in the docs if we went that direction.

@mitschabaude I was also working on adding similar warnings to some of the examples in the o1js repo. Maybe it makes sense to add the caveat(temporary until we completely update the reducer) to the o1js reducer doc comments.

Do you think this location is still an appropriate place to add the caveat?

Yes definitely, it's the right place!

This was the plan. I was deciding if it made sense to either have a short description in this location with the caveat or to link to a longer description somewhere else, and where a long description would live in the docs if we went that direction.

Gotcha, both works. A longer description could live as a new "security best practice" (subsection on the zkapp security docs) here: https://docs.minaprotocol.com/zkapps/writing-a-zkapp/introduction-to-zkapps/secure-zkapps#best-practices-for-zkapp-security